Control of interactions within virtual environments

ABSTRACT

A method for restricting the number of consequential interactions to further virtual objects having a relationship with a first virtual object, resulting from an interaction with said first virtual object. The method comprises: defining a maximum number of consequential interactions, counting consequential interactions, and stopping further interaction when the maximum number of consequential interactions is reached.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/222,810, filed on Mar. 24, 2014, which is a continuation of U.S.patent application Ser. No. 12/216,607, filed on Jul. 8, 2008, now U.S.Pat. No. 8,683,388, which is a division of U.S. patent application Ser.No. 09/887,026, filed on Jun. 25, 2001, now U.S. Pat. No. 7,409,647,which claims the benefit of priority of U.S. Provisional PatentApplication No. 60/233,478, filed on Sep. 19, 2000. The contents of theabove Applications are all incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to methods and apparatus for the controlof interactions within virtual environments, and more particularly, butnot exclusively to control of interactive relationships of threedimensional (hereinafter 3D) objects in distributed 3D environments.

BACKGROUND OF THE INVENTION

Some applications are graphics based, and may, using what is commonlytermed virtual reality, give an illusion of 3D space by situatingvirtual objects on a virtual 3D grid. Using immersion equipment, userscan interact with this virtual environment. Additionally oralternatively, the 3D space can be projected on to a substantially flator 2D surface such as a computer visual display unit (VDU), so thatvirtual objects are viewed on substantially 2D computer screens, yetnevertheless, an illusion of solidity is maintained, and such virtualobjects have, in addition to height and width, an apparent depth. Theseobjects may move with respect to backgrounds or scenes, which may besubstantially stationary, though often may be viewable from differentangles, and if the viewing angle is changed, the whole scene is rotatedin consequence. Alternatively, as with flight simulators for example,the background may constantly change in a dynamic manner.

As illustrated in FIG. 1, which shows schematically theinter-relationships between clients and server in networked computingenvironments, networked computing comprises a plurality of remoteterminals or clients interacting with the same computer application, thebulk of which usually runs on a host computer known as the server. Theclients and the server are interconnected via a network. The individualclients are often at a considerable distance from each other and fromthe host server.

Now the speed at which a computer application runs is a function of boththe complexity of the software, and the capability of the hardware. Innetworked computing however, particularly with data-intensive, heavyapplications, the speed at which applications run is often limited bythe time required for necessary data to be transferred between thenetworked computers. The data transfer time is a function of thebandwidth of the data transfer lines, and of the volume of data thatrequires transporting. Clearly there is a desire to limit the quantityof data that is transported between the client and the server, andefficient programming and data compression techniques are used tofacilitate this data limiting.

The Internet is a multiclient computing environment that potentiallyallows many users to interact with each other using the sameapplication, enabling a large number of players to play the sameadventure game for example. To facilitate multiplayer interaction in a3D virtual graphic environment, in real-time, it is required thatinteractions by one user at one client, are transmitted to the serverand to other clients fast enough that correct sequencing is maintained,thus preferentially the moves of one player appear instantaneously onthe monitors of all other players. Increasing the running efficiency,and, in particular, achieving real-time updating of high-resolution 3Dgraphical displays to multiple users is a challenging aim.

Apart from games and the like, virtual reality has also been applied tovarious areas of human endeavor, replacing real world experimentationwhere, due to economic, safety and other considerations, it has beendeemed preferable to use simulations rather than the real thing.Examples of this include anatomical simulations of the human body forpedagogic purposes in the training of doctors and surgeons, objectdesign for manufacturing and virtual prototyping, guidance forinstallation and trouble-shooting for computer peripherals such asprinters, and battle field simulation for training the military, such asflight simulators for training aircraft pilots, tank drivers andartillery personnel.

As computer programs have got more sophisticated, comprising largerquantities of code, structural programming has given way to ObjectOriented Programming (OOP). The object oriented programming approachbreaks down problems into groups of related parts that take into accountboth the code and the data related to each group. The groups are thenorganized into a hierarchical structure and translated into subgroupscalled objects. Virtual objects are logical entities that encapsulateboth data and the code that manipulates that data.

Object oriented programming has been applied with success to virtualreality computer applications. A virtual object in a virtual realityenvironment can be programmed as a computing object in the sense ofobject oriented programming, thus the appearance or form of the object,its behavior or function, and its location data may be encapsulatedtogether into a quasi-autonomous entity. Programming in this mannerprovides a modular construction that facilitates comprehension ofcomplex programs, for updating and the like. It also avoids the problemsassociated with sharing files between different aspects of a program. Inmultiple-user, real-time networked applications however; the traditionalobject oriented programming approach has been found to be somewhatinadequate. By encapsulating the display and interaction characteristicsof an object with those characteristics that describe function andbehavior, the objects comprise large amounts of data. Transferring suchlarge amounts of data between networked computers requires considerableresources in terms of bandwidth and/or transfer time.

Traditionally, in virtual reality, the placing of objects within a sceneis accomplished by constructing the scene in 3D space on a Cartesiangrid comprising orthogonal axes, or some other coordinate systemappropriate for the specific application. A centroid is then defined foreach object within the scene, and the centroid of each object is thenplotted onto the coordinate system. When an object is moved, thecentroid thereof is repositioned, and the object is redrawn at its newlocation. In some applications, the whole scene may be redrawn. Thus thepositions of objects are defined with respect to the grid, and differentobjects within close proximity may not be directly aware of each other.

A useful software platform for virtual reality applications is GInIt.This has been disclosed; see Shmueli and Elber, [Shmueli O. and ElberG., Managing Data and Interactions in Three Dimensional Environments.Software for Communication Technologies—3^(rd) Austrian-TechnionSymposium, Lintz, Austria, April 1999] which is incorporated herein byreference.

SUMMARY OF THE INVENTION

It is an aim of the present embodiments, to separately store the formand function characteristics of virtual objects, so that user sensiblecharacteristics or the form of the object may be downloaded to userclients, without downloading functional or behavioral characteristics.

It is a further aim of the present embodiments, to control thefunctional and behavioral aspects of virtual objects with dedicatedmodular units.

It is a further aim of the present embodiments, to control consequentialinteractions as will be explained.

It is a further aim of the present embodiments, to provide associationsbetween objects, such that changes in one object automatically triggerdesired changes in associated objects.

It is a further aim of the present embodiments, to control, and moreparticularly to limit, secondary effects of object interactions.

It is a further aim of the present embodiments, to facilitate real timemultiple client interaction with objects within the same networkedvirtual environment.

It is a further aim of the present embodiments, to limit the amount ofdata requiring transfer between the different nodes of a networkedinteractive computing environment, to allow interactions with saidenvironment to be transmitted to all clients in real time.

It is a further aim of the present embodiments to encapsulate thefunctionality of a scene and the objects within it, as a separate,though associated entity from the encapsulation of the display aspectsthereof, thus allowing the association of different functionalities withthe set of objects comprising an existing scene.

These and other aims of the present embodiments will become clear fromthe following description.

According to a first aspect of the present invention there is thusprovided a virtual object for use in an object oriented environment;said virtual object comprising at least a user-sensible aspect andfurther comprising at least a functional aspect; the said user-sensibleaspect being encapsulated as a user-sensible encapsulation, separatelyfrom said functional aspect.

Preferably, the object oriented environment is supported on a computernetwork comprising a first computer linked to a second computer. Theuser-sensible aspect is supported by said first computer and thefunctional aspect is supported by said second computer.

Preferably, the functional aspect is a behavioral aspect.

Preferably, the user-sensible aspect is a display aspect.

Preferably the functional aspect is encapsulated, so as to beexchangeable for an alternative functional encapsulation, thereby toalter the functionality of the said object.

The virtual object may be further at least partly defined by arelationship with a second object. The relationship may involve relativepositioning or movement of the two objects or it may involve color orsound or any other feature of either of the two objects in therelationship.

According to a second aspect of the present invention there is provideda first virtual object within a virtual computing environment, saidfirst virtual object having a relationship with a second virtual object,said relationship being such that an interaction with said first virtualobject is operable to bring about a consequential interaction with atleast said second object.

The relationship may be a direct or an indirect relationship, indirectmeaning a relationship involving at least one mediating interaction withat least one intermediate object.

Preferably, the relationship with the second virtual object is definedby an order number, said order number being equal to the number ofconsequentially interacting objects.

A preferred embodiment has a predetermined interaction limit, and aninteraction stopper operable to prevent further consequentialinteractions occurring once a number of interactions corresponding tosaid interaction limit has been reached.

In preferred embodiments, said predetermined interaction limit isspecific to at least one of an interaction order and an interactiontype, and said interaction stopper is operable to stop interactionswithin said specificity. For example the limit may apply to first orderinteractions only or to first and second order interactions only or tofirst order interactions between objects on the same side or the like.

In preferred embodiments, said consequential interaction with said atleast second object comprises a change in at least one of location,movement, shape, size and color of said second object.

According to a third aspect of the present invention there is provided avirtual reality environment comprising a scene and at least one virtualobject supported by a scene database, said scene database having atleast a first interchangeable functional unit associated therewith, saidfirst interchangeable functional unit comprises functionality for saidat least one first virtual object.

Preferably, said functionality for at least said first virtual objectcomprises behavioral rules.

Preferably, said functionality for at least said first object comprisesrules for determining allowable interactions therewith.

Preferably, said functionality comprises rules for determiningnon-allowable interactions therewith.

Preferably, said functionality comprises rules for restricting allowableinteractions therewith.

Preferably, the first virtual object comprises a user-sensible aspect,the said user-sensible aspect being encapsulated separately from saidinterchangeable functional unit.

Preferably, the user-sensible aspect comprises data for display of saidvirtual object.

Preferably, the interchangeable functional unit is interchangeable toalter the functionality of said virtual object.

Preferably, the first interchangeable functional unit comprisesobject-specific functionality for a plurality of virtual objects.

A preferred embodiment comprises at least one second virtual object, thefirst virtual object being partly defined by a relationship with said atleast one second virtual object.

The relationship may be direct or indirect.

Preferably, the first virtual object comprises a relationship with saidat least one second virtual object such that an interaction applied tosaid first virtual object causes a consequential interaction with saidat least one second virtual object.

Alternatively, the relationship with said at least one second object isan indirect relationship, being a relationship involving at least onemediating interaction with at least one intermediate object.

The relationship with said at least one second object may be defined byan order number, said order number being equal to the number ofconsequentially interacting objects.

A preferred embodiment may have a predetermined interaction total, andan interaction limiter operable to stop further first orderconsequential interactions occurring when a number of first orderinteractions equaling said predetermined interaction total has beenreached.

In an alternative embodiment the interactions that are limited need notbe first order but may be any order or may just be a higher order.Alternatively the interactions may be limited by type rather than order,or a combination of the two may be provided.

In an embodiment, consequential interaction with said at least onesecond object comprises a change in position of said second object. Theinteraction could also comprise a change in color of said second object.

According to a third aspect of the present invention there is provided adedicated control element for controlling the functionality of virtualobjects belonging to a set of virtual objects within an environment,said dedicated control element being associated with said environment,and comprising:

recognition functionality for recognizing whether a virtual objectwithin said environment is a member of said set, and

control functionality for processing events received from saidrecognized virtual object.

According to a fourth aspect of the present invention there is provideda method for facilitating interaction by a plurality of users at aplurality of client terminals with at least a first object, said firstobject having display and interaction characteristics and functionalcharacteristics, in a networked virtual reality environment; said methodcomprising:

encapsulating the display and interaction characteristics in a displaypart of said first object,

encapsulating functional characteristics in a functional part of saidfirst object,

downloading said display part of said first object to user clientterminals, and

retaining said functional part of said first object at a remote locationnetworked with said user client terminals.

According to a fifth aspect of the present invention there is provided amethod for restricting the number of consequential interactions tofurther virtual objects having a relationship with a first virtualobject, said consequential interactions resulting from an interactionwith said first virtual object, said method comprising:

defining a maximum number of consequential interactions,

counting consequential interactions, and

stopping further interaction when said maximum number of consequentialinteractions is reached.

Preferably, said related further objects have a causative relationshipwith said first object.

Preferably, a change in a position of said first virtual object causesconsequential interactions with said further objects.

Preferably, said relationship is direct.

Alternatively, said relationships with said further objects compriseindirect relationships, being relationships involving at least onemediating interaction with at least one intermediate object.

Preferably, the relationship with each said further object is defined byan order number, said order number being equal to the number ofconsequently interacting objects.

Preferably, allowable consequential interactions are restricted to apredetermined number of objects having first order relationshipstherewith.

Preferably, the consequential interaction with said further objectcomprises a change in position of at least one of said objects.

According to a sixth aspect of the present invention there is provided amethod for controlling the functionality of a set of virtual objectswithin an environment, comprising:

incorporating allowable functionality for said set of virtual objectswithin a dedicated control element associated with said environment,

incorporating recognition functionality within said dedicated controlelement to enable said dedicated control element to distinguish betweenvirtual objects within said set and virtual objects not within said set,and

thereby allowing said dedicated control element to control virtualobjects within said set.

According to a further aspect of the present invention there is provideda method for facilitating interaction by a plurality of users at aplurality of client terminals with at least a first object, said firstobject having display and interaction characteristics and functionalcharacteristics, in a networked virtual reality environment; said methodcomprising:

encapsulating the display and interaction characteristics in a displayand interaction part of said first object,

encapsulating functional characteristics in a functional part of saidfirst object,

downloading said display and interaction part of said first object touser client terminals, and

retaining said functional part of said first object at a remote locationnetworked with said user client terminals,

said interactions comprising trading using said objects.

In the following description, the term ‘comprise’, and variationsthereof, such as ‘comprising’ and ‘comprised’ imply that the inventionincludes the elements listed, but is not necessarily restricted to thoseelements, and may additionally comprise other elements.

In the context of this document, words such as solid, object, scene,environment and the like, refer to virtual solid, virtual object,virtual scene, virtual environment and the like, unless the contextclearly implies otherwise.

For brevity, the term ‘mouse’ refers to any cursor-manipulating device,including but not necessarily restricted to a computer mouse, which isan input device for moving an object, often a cursor, on a computervisual display unit (VDU). The term mouse is used herein, reflecting thewidespread usage of the computer mouse for this purpose, however in thiscontext, the term mouse should be understood to also refer to otherinput devices, such as tracker balls, light-pens, keyboards, cursorarrows or other designated keyboard keys, joysticks, paddles or theobject manipulation components of dedicated 3D immersion or virtualreality equipment.

Similarly, the term ‘VDU’ may refer to any display device, particular 2Dcomputer monitors, such as liquid crystal displays (LCD), cathode raytubes, image projectors and screen, and to any similar device. Likewise,the visual components of dedicated 3D immersion or virtual realityequipment are to be considered as within the ambience of this term.

Similarly, the term ‘computer’ is to be understood loosely, to includefor example, portable phones and TV sets when equipped for graphical,networked, interaction.

The present invention relates to objects in an object-orientedenvironment, thus the word object as used herein, refers to anindividual, identifiable item, unit, or entity, with a role in the 3Denvironment, and to all the functions and code associated therewith.

The invention disclosed herein is directed to the effects that changesto an object within a scene have on other objects within that scene, andto ways of structuring computer applications for virtual environments.In the preferred embodiment described herein, interaction with 3Dobjects in 3D scenes is described. It will be appreciated by the readerhowever, that many of the features described herein for 3D virtualreality, may be applied in other embodiments to flat shapes, 2D objects,scenes and the like, mutatis mutandis.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a better understanding of the invention and to show how the same maybe carried into effect, reference will now be made, purely by way ofexample, to the accompanying drawings.

With specific reference now to the drawings in detail, it is stressedthat the particulars shown are by way of example and for purposes ofillustrative discussion of the preferred embodiments of the presentinvention only, and are presented in the cause of providing illustrationof the conceptual aspects of the invention. In the accompanyingdrawings:

FIG. 1 is a schematic diagram showing a networked computing environment;

FIG. 2 is a schematic conceptual diagram illustrating the functionalelements of a prior art virtual object;

FIG. 3 is a schematic conceptual diagram illustrating the functionalelements of a split virtual object and an arrangement thereof, accordingto an embodiment of the present invention;

FIG. 4 is a perspective view showing a chessboard with chessmen thereon,on a table within a virtual reality environment;

FIG. 5 is a flow diagram that illustrates how a command reaching the SDBis processed;

FIG. 6 is a schematic block diagram illustrating how an SDB may compriseexperts associated therewith;

FIG. 7 is a perspective view of the chessboard with chessmen thereon, ona table within a virtual reality environment of FIG. 4, with a whitepawn, having been removed from the chessboard and placed on the tabletopto the right thereof;

FIG. 8 is a perspective view of the chessboard with chessmen thereon, ona table within a virtual reality environment of FIG. 7, with the tablemoved forward, leaving the chessboard and pieces behind;

FIG. 9 is a side view of a plurality of dominoes;

FIG. 10 is a flow diagram illustrating an interaction counter mechanism;and

FIG. 11 is a tree diagram showing the hierarchal relationships between aselected object and directly and indirectly related objects.

DESCRIPTION OF SPECIFIC EMBODIMENTS OF THE INVENTION

Before explaining at least one embodiment of the invention in detail, itis to be understood that the invention is not limited in its applicationto the details of construction and the arrangement of the components setforth in the following description, or illustrated in the drawings. Theinvention is applicable to other embodiments or of being practiced orcarried out in various ways. Also, it is to be understood that thephraseology and terminology employed herein is for the purpose ofdescription and should not be regarded as limiting.

Embodiments of the invention are applicable to a virtual environmentthat enables a plurality of users to interact with each other. Preferredembodiments are designed for networked computing environments,particularly very large, open networked environments such as theInternet.

Reference is now made to FIG. 1, which is a simplified block diagramshowing how a plurality of networked users may interact within the sameenvironment. FIG. 1 comprises three users 11, 12, 13 at client terminals21, 22, 23 each connected to, or logged on to, a single server 50 via anetwork 25.

An interaction, made by a first user 11 interfacing with a first clientterminal 21 is coded at the first client terminal 21, and transmitted tothe server 50. The server 50 sends data to all logged on clients 21, 22,23 updating them regarding the interaction. Networked environments ofthis nature may comprise many clients, and may also comprise a pluralityof servers, or alternatively, a server that is, itself, distributed overa number of host computers on different nodes of the network.

The environment optionally comprises sophisticated, non-static, 3Dscenes, optionally having a detailed 3D background, which may beviewable from different vantage points, and optionally comprises alimited, discrete number of objects selected from an almost infinite setof objects, that, because of the dynamic nature of some applications,may not even have been conceived by the original designer of aparticular application. The various scenes are stored in a scenedatabase, henceforth SDB 60.

The present embodiments provide a novel way of structuring software thatis particularly appropriate to enabling a plurality of users to interactwith scenes containing multiple objects within graphical applicationsfor networked virtual environments. In some embodiments the objects thatmay eventually populate a scene may not be known in advance, and may noteven have been defined when the scene was created. Also, differentbehaviors may be assigned to existing display elements.

It will be appreciated that the SDB can be used to monitor interactionsoriginating with users, thereby to learn about individual users andtheir tastes and preferences.

A first preferred embodiment has four features that are describedherein. The first feature is referred to herein as object splitting, thesecond feature as expert control, the third feature as relationships andthe fourth feature as counter control.

Object Splitting

The first feature, known as object splitting, is a departure from theclassic object oriented conception that considers an object to be anintegral, autonomous unit, wherein all the data and code relating to theobject is encapsulated within the object, that is, kept together in oneplace. Instead, the data and code comprising the object is divided intosub-units, each of which is encapsulated separately, and may be kept andimplemented separately at the most suitable location. Thus, the displayaspects of an object may be located at a client terminal where theobject is displayed, and behavioral aspects for example, are locatedelsewhere. The separation of form and function in this manner alsoenables different functionalities and behaviors to be associated withthe same display element. Although Object Oriented Programming (OOP) isvaluable as a means of ensuring that different elements of complexprograms are kept independent to some degree, minimizing undesirableinterference and facilitating program maintenance, it has twodisadvantages in particular: firstly, that the same object always hasthe same behavior, and secondly, that for virtual objects to displaycorrectly at all nodes of a network such that users can interacttherewith, the whole object, which invariably comprises relatively largeamounts of data and code, must be transmitted to and from nodes of anetworked environment. In object splitting however, there is aseparation between aspects of the object that require downloading to theindividual nodes so that the object is user sensible, and between otheraspects of the object that need not be downloaded. This has two mainadvantages: firstly, a different behavior or function can optionally beascribed to a rendered object as displayed, and secondly, the amount ofdata requiring transmission between nodes may be limited to thatrequired for display purposes, which may result to greater runningefficiency.

Reference is now made to FIG. 2, which is a schematic conceptualdiagram, showing the components of a typical prior art object 100. Aprior art object 100 optionally comprises user-sensible characteristics110, which may include visible display characteristics 120 such ascolors 122, shape and form 124 and size 126, and may further includeaudible characteristics 130 such as associated sounds having volume 132,pitch 134 and overtones 136. Using suitable immersion equipment andinteracting with the appropriate sense organs of the user, the objectmay, at least theoretically, also have a smell, a taste and a texture.The prior art object 100 further comprises functional and behavioralcharacteristics 150 such as scripts 160 and the like which are fixedcharacteristics of the object once the object has been compiled. Inaddition, the prior art virtual object 100 further comprises positioningcharacteristics 180 such as absolute Cartesian coordinates 190 withrespect to the orthogonal axes of the 3D space.

All the above mentioned characteristics of the prior art object 100 areencapsulated as a single unit 101, and for the prior art object 100 tobe available to any client 21, 22 or 23 (FIG. 1), for display and/orinteraction thereat, in a networked environment, the entire prior artobject 100 including all the code and data necessary for allcharacteristics must be made available to that client 21, 22 or 23.

Since all the aspects of a prior art object 100 are traditionally kepttogether, whenever the object is introduced into a scene, all theassociated data and code is required to be downloaded to all logged onclients 21, 22, 23 viewing or interacting with the scene. All logged onclients 21, 22, 23 require updating in real time, of any interactionwith the object, such as the object being moved by one of the clients,for example. In consequence, networked virtual reality applicationscomprising prior art objects usually require very large amounts of datato be transported between scenes, and since this type of softwarestructure generally requires prohibitively large bandwidth or isunacceptably slow running, it is not ideal for networked computing, andputs an unacceptable data transfer requirement for Internet basedapplications requiring interaction between many users.

Reference is now made to FIG. 3, which is a schematic conceptual modelof the first feature of the present embodiment, known as objectsplitting. FIG. 3 shows how code and data relating to user-sensiblecharacteristics 210 of, and to the positioning characteristics 280 ofthe object 200 may be encapsulated as a split object user display part202, independently of the functional and behavioral characteristics 250which may be encapsulated as a functional and behavioral part 251. Theuser-sensible characteristics 210 again optionally comprise visibledisplay characteristics 220 such as colors 222, shape or form 224 andsize 226, and audible characteristics 230 such as associated soundshaving volume 232, pitch 234 and overtones 236. Here again, usingsuitable immersion equipment and interacting with the appropriate senseorgans of the user, the object may, also have a smell, a taste and atexture. Position characteristics 280 optionally include coordinates 290that relate the object 200 to its absolute position in the virtualspace, and optionally include relative positioning 295 of the objectwith respect to other objects within the scene. Functional andbehavioral characteristics 250 optionally include interaction with otherobjects 275.

Non-display-related characteristics such as functional and behavioralcharacteristics 250 optionally reside elsewhere in the networkedenvironment than the location of the split object user display part 202,which comprises user-sensible characteristics 210 and positioningcharacteristics 280. The aforementioned non-display-relatedcharacteristics might reside on the server 50 for example, and mayoptionally comprise rules of play 260, rules of behavior 270 and thelike, and may optionally be structured as, and controlled by experts, aswill be explained in detail below.

Structuring objects in this split form, enables only the split objectuser display part 202, i.e. the parts of an object 200 that relate toits user-sensible detectivity 210, specifically its visual displayaspects 220, to be downloaded to the client terminal 21, 22 or 23. Bynot downloading characteristics relating to the functionality andbehavior of the object 250, and retaining them centrally for example,object splitting enables the quantity of data that requires transportingbetween networked nodes to be considerably reduced, and facilitates themaintaining of control centrally, without compromising on how objectsare displayed at the individual client terminals.

The split object user display part 202 comprises all user-sensibleaspects of the virtual object, that is, all aspects that may bedisplayed at the user client terminal 21, 22, 23. These include detailsof the position 280 and visible characteristics 220 (appearance) of theobject 200, but also other characteristics that may be sensed, such asaudible characteristics 230 (associated sounds). Special immersionequipment may, in addition, provide a virtual taste, smell or touchsensation, and these characteristics may, where available, also comprisethe split object user display part 202.

The split object user display part 202 is preferably available via thenetwork 25, and may be downloaded to the client terminal 21, 22, 23 ofany logged on user 11, 12, 13 so that the object 200 may be displayedwithin the virtual environment. The other characteristics may beencapsulated as a split object function and behavior part 251. Thisnon-display part remains in the scene database 60, and is not downloadedto the client terminal 21, 22, 23. The non-display part may, in otherembodiments, be stored in a plurality of locations, distributed aroundthe World Wide Web for example, as a distributed database. The displayaspects of the objects that are downloaded to the user terminal, may, ofcourse, not actually be stored in the scene database, which may merelyreference the locations of the display aspects, for downloading, thelocations being distributed around the Internet. Furthermore, asmentioned above, one may use the SDB to learn the behaviors of users forfuture reference.

Storing the display aspects of an object, separately from the functionaland behavioral aspects enables the same objects to be assigned differentbehaviors and used in a variety of scenes. Thus for example, a counterrestricted to two dimensional space may be used for Snakes-and-Laddersor Ludo, or alternatively be assigned three dimensional mobility, andallowed to move in 3 dimensions and then used for tiddlywinks. Similarlythe same artwork may be used with one set of functions on one scale, asa virtual toy or model, and on another scale as a representation of thereal thing, for example.

Reference is now made to FIG. 4, which is a perspective view of a table300 having a Right side 310, a chessboard 320, white chessmen 330, andblack chessmen 340. Particular attention is drawn to the black rook 341on C8, the black king 342; the white pawn 332 on G2, and to squares C8,G2 and C6.

Optionally, by incorporating the object-splitting feature, only thedisplay aspects of chess, i.e. the appearance of the board and chessmenneed be downloaded to the user terminal. Then, as a player moves achessman, only details of the move require to be transmitted to thescene database 60 for optional evaluation, and so that the server, thesecond player, and any observers, are updated regarding the move.

With reference now to FIGS. 1, 3 and 4, for the scene illustrated inFIG. 4 to be correctly displayed on a client terminal VDU 31, 32, or 33,the coordinates 290, form 224 and color 222 of the table 300, thechessboard 320, and all chessmen 330, 340 must be downloaded to theterminal VDU 31, 32, or 33. The functional aspects of the chessmenhowever, such as the legality of a particular move, such as moving theblack rook 341 from C8 to C6 for example, need not be downloaded.

Expert Control

The object splitting feature is a concept that can be generalized, andapplied to the scenes themselves, or to parts thereof, to provide thesecond feature of the present invention which is a generalized form ofthe concept of the first feature, but wherein the functionality isapplicable to sets of objects. Such functionality of sets of objectswithin a virtual environment becomes dissociated from the objectsthemselves, and thus may be associated with the 3D environment.Controlling sets of objects in this way is referred to herein as expertcontrol. Thus, the second feature, expert control, is a way of handlingsets of objects and events in the context of flexible 3D virtualenvironments, wherein for example, different scenes may be displayed,new objects can be introduced in real time, relationships betweenobjects can be modified and graphic properties of objects can bechanged.

Expert control is provided by dedicated control elements, referred tohereinbelow as experts, and using experts is a way of structuringapplications to provide functionality to objects at the SDB level. Thescene database (SDB) itself facilitates the display of the differentobjects within the various scenes, and allows interactions of a generalnature, such as the moving of the various objects, and their removalfrom a scene. In particular applications, where there may be a need fora more specialized and dedicated control over parts of scenes, expertsmay be provided. These experts are dedicated program elements externalto the objects themselves, associated with the scenes, but optionallyavailable as modular add-ons to the scene database 60.

An application where using an expert would be advantageous is forplaying chess. Chess is a game played by a well-defined set of rules.These rules, include for example, (i) set the chessmen in their startingpositions, (ii) ensure that White starts, (iii) only allow one chessmanto occupy any square at any one time, (iv) assign the legal moves to thedifferent types of chessmen, (v) require the players to take turnsmoving, and (vi) force a player whose king is in check to remedy thesituation.

Although chess must be played in accordance with these and other rules,the rules themselves may be kept as part of an autonomous program unitor expert, which may be retained at the server for example. And, if amove made by a user is not an allowable move for that chessman, the movemay be rejected by the expert.

Experts may be implemented as shared libraries, for example, as DLLsunder the Win NT/98 operating systems. Experts are preferably associatedwith the scene database (SDB), and all SDB commands that concern thedomain of expertise are handled thereby. In a preferred embodiment anexpert is called up as a result of a user-interaction with an object.Thus if a user interacts with an object at his client, the object sendsa message to the SDB. Each expert that successfully connects with ascene may register as a valid SDB expert, and any message or commandthat arrives at the SDB will be passed in turn through all valid expertsuntil processed.

Each valid expert determines whether a command is of relevance toitself, in which case, the expert will process that command. If thecommand is not relevant to the expert, or no response is appropriate,the command is returned to the SDB, which preferably passes the commandon to the next valid expert in turn. If there are no other validexperts, the SDB 60 processes the command itself. Thus the functionalityand behavior of objects within a scene may be handled by an expert andthe display aspects of the scene may be handled by the scene database.As described above, changes of a functional or behavioral nature areconsidered before the display aspects. This order, can, of course bechanged around.

By command processing, as well as sending the command for execution,such things as changing or deleting the command or spawning new commandsare included. Once processed, a command is not passed on to furtherexperts. Experts do not interact directly with the clients or with SDBdata. Instead experts perform interactions indirectly, employing the SDBcommand mechanism.

Reference is now made to FIG. 5, which is a functional block diagramthat illustrates how a command reaching the SDB is processed. FIG. 5shows a command 400, the scene database or SDB 60, a query regardingadditional experts 410, a next expert 420, a conceptual indication ofhow a command is passed on 430, the SDB command handler 440, a relevancequery 450, a conceptual indication of how a command is passed back 460,a conceptual indication of how a command is processed 480 and responsecommands 490. A command 400 reaches the scene database or SDB 60. Anexpert query 410 regarding the existence of additional experts 410 isasked. If the response to the expert query 410 is YES, indicating theexistence of further experts, the command is passed on 430 to the nextexpert 420. At the next expert a relevance query 450 is asked, that isto say, the expert decides whether it may process the command. If notrelevant, the command is passed back 460 to the expert query 410. If thecommand is relevant however, that is, if the current expert may processthe command, the current expert 420 processes 480 the command, and theprocessed, i.e. altered command, and/or new commands spawned thereby490, are passed on to the SDB command handler 440. All response commands490 whether generated by the experts 420 or by the SDB 60 itself, aretransmitted from the command handler 440 to the network 25, whence allclients are informed of resulting changes. If an expert 420 cannothandle a command, the command is sent back to the SDB 60, which againqueries whether there are more experts 410, if the answer is positive,the next expert in line is passed the command. If the answer to the moreexpert query 410 is negative however, i.e. if there are no more experts,the command is passed on 415 to the command handler 440 of the SDB,which handles the commands directly.

Command processing by the SDB with experts as described above, may beillustrated using a games example. Suppose an SDB is managing scenes ofvarious table games, enabling a plurality of clients to compete inBackgammon, Checkers, chess and Snakes & Ladders tournaments forexample. This is shown in FIG. 6 below.

Reference is now made to FIG. 6, which is a schematic block diagram thatshows how a first user 11 at a client 21 may play an interactive game ofchess via a network with a second user 12 at a second client 22. Theuser 11 views the scene via his VDU 31, and makes interactions therewithvia his mouse 51. The split object user display 500 and interaction 510parts are downloaded to the client 21. The clients are linked via thenetwork 25, to an SDB 60 on a server. The SDB 60 is linked to aplurality of experts such as a Backgammon expert 530, a Checkers expert540, a chess expert 550 and a Snakes & Ladders expert 560. The chessexpert preferably comprises individual chessman expertise; for exampleking expertise that knows about the movement rules for a king. The chessexpert 550 preferably further comprises other chess-specific functionssuch as board display 558 and checking 559. The SDB itself directlyhandles the alternation of moves 570, the positioning of pieces on thegame boards 580 and the removal of pieces from the various games 590. Inother words, the SDB merely controls the graphical display, and allowsthe manipulation of chessmen and other display elements. The SDB knowsnothing regarding their function or allowable behavior.

The user 11 views the position as displayed on his VDU 31, and interactstherewith, via his mouse 51. Only the split object user display andinteraction parts 500 of the chessmen 330, 340 (FIG. 4) and chessboard320 are available at the client 21. Thus if the user 11 decides to movea rook 341 and selects it using the mouse 51 and repositions thechessman thereby, a signal is transferred to the SDB 60 via the network25. The legality of the move and how the rook moves and displays withrespect to the chessboard are functions controlled by the SDB 60 on theserver 50.

The SDB 60 allows object manipulation and display, and is preferably ofa general nature. Thus if a games application SDB 60 is considered, theSDB 60 itself may handle the common aspects of board-games such as thealternation of moves between players 570, the positioning of pieces onthe squares of the game-board 580, and their introduction to and removalfrom the board 590. Alternatively, some or all these functions may beassigned to experts as deemed appropriate.

Referring back to FIGS. 2, 4 and 6; with Black to play, and wishing tomove the rook 341 from C8 to C6, if the user 11 playing Black selectsthe rook 341 on C8 and moves it to C6 with his mouse for example, themove arrives as a command at the SDB 60 and is passed on to theBackgammon expert 530 first. Not recognizing the grid coordinates or theobject rook 341, the Backgammon expert 530 does not interact with thecommand, and returns it to the SDB 60. The SDB 60 passes the command tothe next expert 430, which is a Checkers expert 540. The Checkers expert540 does not recognize the rook 341, and thus passes the command back560 to the SDB 60. Turning to the next expert in turn, the command isnow addressed to the Chess expert 550, which recognizes both the rook341 and the coordinate system.

The Chess expert 550 queries the move 450, checks that there is a Rook341 on C8, that it is Black's turn to play, that such a move is legal,that is, does not expose the Black King 342 to check for example. If themove is deemed legal, that is if it satisfies the rules of chess, thecommand is accepted, if not, an illegal move response is generated. TheSDB does not pass on the command to further experts such as the Snakes &Ladders expert 560, but accepts or rejects the move, and if the move isaccepted, an appropriate command to implement the move is sent to alllogged on clients 21, 22 and 23 viewing the relevant scene. Since theChess expert 550 processes the command, the command is not passed on tothe Snakes & Ladders expert 560 at all. In the specific examplediscussed above, the move is rejected as C6 is occupied by a black pawn,and two pieces cannot simultaneously occupy the same square.

As shown above, structuring applications using object splitting toseparate the displaying of objects from their behavior, or to separateform from function, and then to control the behavior of objects usingexperts, is an effective way of enabling multiple user interaction witha plurality of objects in dynamically changing scenes in a networkedenvironment, enabling the introduction of extra objects at any stage, ina modular manner. The advantages of this structure are that greatflexibility is ensured, and objects with restricted allowable behavior,or even a complex of associated objects having a complex list ofassociated rules such as a chess-set, can be introduced into a scene,and scenes may be provided, having a unified behavior for a variety ofobjects.

In an embodiment known as a mapper, shown in FIG. 1, dynamicallychanging data received from an external source may be used to affectobjects in a three-dimensional scene. For example, the 3D scene maycomprise bars of a bar chart and externally received data may set theheight and/or color of the bar. Thus the bars of a bar chart may beupdated dynamically, and used for following stock market movements orcurrency fluctuations dynamically. The external data may come from anexternal website on the Internet for example.

The same scene could also be used to enable the remote monitoring inreal time, of vitality data of a patient, where sensor signals could betransmitted to the same scene. Indeed, the same dynamically changingdata could be displayed using a variety of appropriate graphic displayforms.

The present embodiment comprises two further features: relationships andcounter control. These two features are ways of controlling the behaviorof objects, such that when an interaction occurs with a selected object,other objects, associated with or having a relationship with theselected object, also participate in the interaction. Such interactionsinclude color changes, status changes, movement changes etc.

Relationships

Relationships are a way of allowing a trigger applied to a first objectto cause changes or actions to be applied to other objects. Therelationship feature, as will be described below, enables a first objectto be comprise an association or a link to one or more other objects

In the prior art, problems occur such as the following: Prior artobjects are traditionally located by their absolute positions in virtualspace, not by any association with other objects. If a prior art objectis moved, it will generally have no effect on other objects in itsvicinity. For example, if a chessboard is moved, since the chessmenthereon are separate objects, the chessmen thereon are not moved. Theystay where they are in virtual space and in consequence, the chessboardmoves with respect to them. That is, their position relative to thechessboard changes.

To illustrate the problem in more detail, reference is made to FIG. 7,with respect to which, the effects of various interactions with thechess scene shown in FIG. 4 are illustrated.

With reference now to FIG. 7, which shows the chess position of FIG. 4,with one change—the white pawn 332 has been removed from square G2 ofthe chessboard 320 and placed on the right side 310 of the table 300.Such a move could occur as pieces are manipulated to set up a chessposition, for a chess problem for example. When moving from the sceneshown in FIG. 4 to the scene shown in FIG. 7, since the pawn 332 hasbeen moved in virtual space, and the table 300, board 310 and otherchessmen 330, 340 were not moved, the position of the pawn with respectto table 300, board 310 and other chessmen 330, 340 is changed. That is,the pawn is moved in absolute terms, with respect to the coordinatesystem of the scene, independently of the other objects in the scene.This type of independent repositioning of objects in virtual realityscenes is known in the prior art, and for some applications is adequate.

The independent movement of selected objects has limitations however.Starting from the position shown in FIG. 7, having moved the pawn 332,if now the table 300 is moved, perhaps towards the user, the scenefollowing prior art repositioning norms, will appear as illustrated inFIG. 8. Since the chessboard 320 and chessmen 330, 340 have not beenmoved, and since they are positioned in absolute terms in virtual space,the chessboard 320 and chessmen 330, 340 remain in their previouspositions. That is, the movement of the table 300 leaves behind thechessboard 320 and chessmen 330, 340, and, for many applications, thistype of result would be considered undesirable. In contrast, to betterreflect the behavior of a real table, chessboard and chessmen, one mayrequire that moving the virtual reality table 300 of FIG. 7 results inthe chessboard 320 and chessmen 330, 340 moving with it.

The third feature, relationships, is a way of overcoming theaforementioned problem. Using relationships, virtual objects are linkedtogether so that they may interact together, so that a trigger appliedto a first object causes changes to be applied to related objects. Forexample related objects may be moved together, keeping the same relativepositioning there between. Other possible interactions includeassociated pieces undergoing color changes together, making a move in achess game, may start one's opponent's chess clock ticking, or a stretchapplied to a first object may be applied to associated objects. In apreferred embodiment, the relationships applied to an object are storedin a table. A trigger applied to the object preferably has a definitionas to types of relationships to which it applies, and the table issearched to find those objects having the defined relationship type. Thetrigger is then used to apply an action to the objects found. The actionmay be the same as that applied by the trigger to the first object or itmay be something different. For example the trigger may be selection ofan object with the right mouse button. The selected object is caused tofire a gun. Related objects are any objects belonging to a group “enemy”which are in the line of fire, and the trigger causes the relatedobjects to suffer damage.

The relationships feature may be further illustrated by considering achessboard with chessmen thereon, and a chessman, such as a pawn,associated therewith, but not situated thereon as shown in FIG. 7.Considering the chessboard 320 now, let us imagine that, instead ofmoving the table, the chessboard is moved. To better reflect reality andto avoid the problem described above, the chessmen 330, 340 thereon maybe defined as having a motion relationship with the chessboard 320. Thusif the chessboard 320 shown in FIG. 7 is selected and moved away fromthe table 300, to be eventually put down elsewhere, on another piece offurniture perhaps, the chessmen thereon can be defined as having arelationship therewith, reflecting real world behavior, and the chessmenwill move with the chessboard. The above example illustrates apositioning relationship comprising a vertical juxtaposition, wheremoving a lower object having such a positioning relationship with anupper object causes the upper object to move with it, in the manner thatreal world objects in vertical alignment will move together. In avirtual environment, positioning relationships between objects mayresult in consequences that do not reflect the behavior of real worldobjects however.

A relationship may reflect a conceptual type of associativerelationship, such as Keep With or Keep In Same Relative Position With.Here, the association may not reflect the physical behavior of realobjects in the real world. As illustrated by comparing the scene in FIG.7 with the scene in FIG. 8, associated objects not actually in play, mayalso have a relationship with the chessboard 320. It may be advantageousif the chessboard 320 is moved, for the pawn 332 that has been removedfrom the chessboard 320, to move therewith as well, keeping its samerelative position with respect to the chessboard 320, despite it beingremoved from, that is situated off, the chessboard 320. This is shown inFIG. 8, where all chessmen including the pawn 332, move with thechessboard. Although this behavior is not analogous to the real worldbehavior of chessmen and chessboards, it is a useful feature. It isparticularly valuable if, for example when the chessboard is selectedand removed from the scene completely, all chessmen, whether situated onthe board, or, as in the case of the white pawn 310, are situatednearby, are removed as well.

Relationships of this type typically have a move-with nature, such thata first object having a move-with relationship to a second object willretain a relative position with the second object as it is moved. Arelationship of this type may be a one-way relationship, in which case,if the second object is moved, the first object moves with it, butmoving the first object, has no effect on the second object.Alternatively, a relationship of this type may be a two-wayrelationship, in which case regardless of which object is activelymoved, the two objects remain together. A one-way relationship is thetype preferred for chess scenes for example, where moving a chessboardin virtual space results in the chessmen moving in virtual space suchthat there is no relative movement between chessboard and chessmen,however the movement of a single chessman does not affect the position(in absolute terms), of the chessboard or other chessmen. In contrast, atwo-way relationship may be the relationship between a virtual cyclistand a virtual bicycle for example, where it may be desirable to keep thecyclist and bicycle together regardless of which is selected and moved.

Example

Working embodiments of the present invention were implemented in GInIt,which is a scene database that provides a multiple-user networkedenvironment that is adapted to the introduction of objects into scenes.

GInIt uses the C++ programming language, which is a language adapted toobject Oriented applications, and is thus well suited to virtualreality.

To facilitate the relating of one object with another, three types ofrelationships were defined; a first type is an explicitly establishedrelationship. Chessmen 330, 340, on a chessboard 320, enjoy arelationship of this type. A second type of relationship is a queryrelationship. This type of relationship results from a query expressedin the database query language. Preferably, in the query type ofrelationship a set of related objects is defined at the time the triggeris applied by conditions obtained in the query. The query relationshipthus allows dynamic relationship establishment and the same trigger maybring about interactions with different objects at different times.

Finally, an object may be related to itself, meaning that the query mayrelate to a property of the object itself.

Counters

A fourth feature of this embodiment, referred to herein as counters, isa family of restriction mechanisms that may prevent interactionsoriginating from a first object in virtual space spreading to anunlimited number of directly and/or indirectly associated furtherobjects.

There is an inherent problem with allowing selected objects to haverelationships with other objects in their vicinity, in that interactingwith an object may result in consequential further reactions; that is,in uncontrollable or undesirable consequences and knock on effects sincethe other objects themselves have relationships with further objects.

Reference is now made to FIG. 9, which uses dominoes 901, 902, 903 toillustrate what is meant by consequential further reactions. Knockingover domino 901, results in domino 902 being knocked over as a directconsequential reaction. If, in consequence of domino 902 falling, itknocks over domino 903, domino 903 can be considered as being knocked asan indirect consequential reaction. The falling of domino 902 may alsobe considered a first order consequential reaction, and that of domino903 may be considered a second order consequential reaction. Subsequentconsequential reactions are labeled third order, fourth order and so on.

In many applications only small numbers of consequential furtherreactions occur in a controlled manner to a small set of interactingobjects. But uninhibited, relationships between objects may result inloops of consequential further reactions of the type A>B>C>A,where>implies ‘moved in consequence with’. This may result inundesirable infinite loops of consequential further reactions of thetype that could lead to a virtual person picking himself up by tuggingon his shoelaces. Alternatively, one object may enjoy a relationshipwith a further object, which itself is related to a further objectforming a long, open ended, uncontrolled chain of objects that may movein response to a selected object being moved. It is to prevent problemsof this nature, that the fourth feature, known as counters, isintroduced.

Counters are a means for restricting consequential further reactions.Three types of counters are defined: (i) Limited number of consequentialfurther reactions to directly related objects, (ii) Limited total numberof consequential further reactions to related objects, and (iii) Limitednumber of dependency levels for consequential further reactions. Theinteractions considered by the counter may comprise all interactions ofthe given order or just those interactions for a defined set of objects.

(i) Reference is now made to FIG. 10, which is a flow diagramillustrating a method for limiting the total number of consequentialfurther reactions to related objects, by using a counter mechanism thatkeeps tally of related reacting objects. If an object is selected 600,using a mouse for example, and the object is moved 610, the movement ofthe object causes the reacting objects counter to be set to zero. Theobject has a related reacting objects counter total limit of n. Now, theexistence of an object having a direct relationship with the selectedobject is queried 620, if there is a further object having arelationship, it is moved and the directly related reacting objectscounter total is adjusted to the previous total+1, that is a runningtotal is kept 630, If the adjusted running total is less than the limitn 640, the existence of an object having a relationship with theselected object is again queried 620. If not, that is, if the totallimit of n is reached, further movements of related objects are notallowed, and the associated movements end 650. If the response to thefurther directly related objects query 620 is negative, that is, thereare no further directly related objects, the associated movements ofrelated objects end 650. Thus if a chessboard is considered, a limit ofnot less than 32 associated objects would be required to enable allchessmen to move with the chessboard, at any stage of a chess game. Ifin addition, to the chessmen, it were deemed desirable for otherobjects, such as a chess-clock to be directly related to the chessboard,a higher limit to the allowable number of directly related objects wouldbe required. For many objects however, such as chairs, boxes and thelike, in many applications, a more modest number of directly relatedreacting objects would be acceptable. In the above example therelationships involved were all direct or first order relationships.However the counter could also be applied to interactions stemming fromany order of relationship or all orders of relationship. Likewise thecounter could be applied to relationships of different types, forexample all chess pieces of the same color.

(ii) Referring again to FIG. 10, an example is given in which thecounter mechanism is applied to any relationships of whatever order.Instead of just limiting the number of reacting objects directly relatedto a first object, it may be preferable in some embodiments, to limitthe total number of directly and indirectly related objects associatedwith a first, directly moved object. A directly related object is anobject having an express relationship with an object actively moved, bya user interaction for example. In contrast, an indirectly relatedobject is an object that is only related to the object actively movedvia an intermediate object. If an object is selected 600, using a mousefor example, and the object is moved 610, the movement of the objectcauses the relationship counter to be set to zero. The object has acounter total limit of n. Now, the existence of an object having arelationship with the selected object is queried 620, if there is afurther object having a relationship, whether it is directly related, orwhether it is indirectly related by having a relationship with a furtherobject that has a relationship with the object that is selected, therelated object is moved and the counter total is adjusted to theprevious total+1, that is a running total is kept 630, If the adjustedrunning total is less than the limit n 640, the existence of an objecthaving a relationship with the selected object is again queried 620. Ifnot, that is, if the total limit of n is reached, further movements ofrelated objects are not allowed, and the associated movements end 650.If the response to the further related objects query 620 is negative,that is, there are no further related objects, the associated movementsof related objects end 650.

This can be overly restrictive however, thus considering the chess scenein FIG. 8 again, if the total number of directly and indirectly relatedobjects associated with the table is limited to say 11 objects, that isn=11, it proves impossible for moving the table to result in thechessboard and pieces moving with it. The chessboard 320 will move, aswill the pawn 332 that is directly related to the table 300, but only afurther 11-2 objects may move, and if, for example the applicationconsiders black chessmen first, the nine black chessmen 340 will movewith the chessboard 320, and thus with the table 300. The white chessmen330 however, will not be moved because of this counter restriction, andwill be left behind. This may result in the scene as shown in FIG. 10where the black chessmen 340 maintain their position with respect thechessboard 320 and table 300, as does the pawn 332 that is resting onthe table 300 at the right side 310 thereof. Whereas the white chessmen330, as the total related objects counter has reached the number 11, donot move with the table, and remain in their previous positions invirtual space, as defined by their coordinates therein. Although notparticularly suitable for chess-scenes, this type of limitation isimportant for more open-ended virtual reality applications, such as Thetype of counter described above need not count all related objects. Thesame counter may count objects restricted to a subset. Thus referringagain to a chess example, only chessmen may be counted, and otherobjects associated with a chessboard, such as chess-clocks, may beignored by the counter. Alternatively, only white chessmen may becounted.

A plurality of counters may also be used with the same object. Thisfeature may be useful in warehousing and stock control for example,where say, five objects of one type, and twelve objects of another arecounted. The first counter described, that only counts directly relatedobjects, may also only count a subset of objects, mutatis mutandis.

Reference is now made to FIG. 11, which is a schematic tree diagramshowing the hierarchal relationships existing between a selected object800, and both directly related objects 810 and indirectly relatedobjects 830. Objects may be assigned a number order that describes theirrelationship with a selected object, thus objects having a directrelationship to a selected object 800, are considered directly relatedobjects 810, and have a level one dependency. Objects only related tothe selected object via an intermediate, directly related, level-onedependency object 810, are considered indirectly related, level-twodependency objects 820. Objects only related to the selected object viatwo intermediate objects, that is objects directly related to level-twodependency objects 820 are considered level-three dependency objects830, and so on.

A third type of counter may set an upper limit on the number ofdependency levels that may suffer a consequential reaction as a resultof an interaction with a first object. Thus a limitation can beconsidered that only allows objects having a relationship of a level notfurther removed than a specified dependency type to move with theselected object. For example, if a level one dependency is applied tothe chess scene shown in FIG. 8, if the table 300 is moved, thechessboard 320 and the white pawn 332 will move in consequence of thetable 300 being moved by a user, since they are directly linked to thetable. The chessmen on the board 330, 340 however, will stay where theyare in virtual space, and are left behind when the table is moved, sincethey are only indirectly linked to the table via the chessboard, andthus have a level two dependency. Again, for tables having objects withassociated objects thereon, a less restricting limitation, such as alevel two dependency, may be more appropriate.

Example

A preferred embodiment of the present invention comprises a distributed,real time and interactive three-dimensional system, the core of which isa memory resident, real-time, object-oriented database called the SDB(scene database). By incorporating the new features of split objects,experts, relationships and counter control as described herein, it ispossible to facilitate controlled multi-client interaction with 3Dvirtual reality applications, with the individual users using standard2D input devices such as the computer mouse for interacting with theprogram.

The separation of the form and function of objects and scenes simplifiesthe way in which data from an external source may be used to dynamicallycontrol and update a scene. Furthermore, separation of form and functionpermits data coming from different sources to be represented byessentially the same scene.

A prototype of the preferred embodiment was developed in GInIt,wherewith the 3D virtual reality was perceived on standard 2D computermonitors, and was also perceived using special immersion equipment. ASolid Modeler was used for object rendering and for animations.

The scene database was implemented in C++ and enables a large number ofusers to interact with a relatively small number of objects. The SDB wasfurther developed to allow the creation of new objects in real-time.

In addition to other features of the scene database, the prototypecomprises the four features of object splitting, expert control,relationships and counter control as described herein.

There is thus provided a virtual environment comprising objects showingthe feature of object splitting, where some of the functionalities ofthe objects are controlled by expert control, using experts associatedwith the environment. Relationships may exist between objects within theenvironment, and extent of consequential interactions resulting fromthese relationships, may be limited using counter control. It will beappreciated however, that these features may be provided eitherseparately or in any combination.

It will be further appreciated by persons skilled in the art that thepresent invention is not limited to what has been particularly shown anddescribed hereinabove. Rather the scope of the present invention isdefined by the appended claims and includes both combinations and subcombinations of the various features described hereinabove as well asvariations and modifications thereof, which would occur to personsskilled in the art upon reading the foregoing description.

It will be further appreciated that certain features of the invention,which are, for clarity, described above in the foregoing description inthe context of separate embodiments, may also be provided in combinationin a single embodiment. Conversely, various features of the invention,which are, for brevity, described in the context of a single embodiment,may also be provided separately or in any suitable combination orsub-combination.

What is claimed is:
 1. A dedicated control element for controlling thefunctionality of three-dimensional virtual objects belonging to a set ofthree-dimensional virtual objects within a distributed three-dimensionalvirtual environment, said dedicated control element being associatedwith said environment, and comprising: a set identifier configured todetermine whether a three-dimensional virtual object within saiddistributed three-dimensional virtual environment is a member of saidset, and a set controller configured to process events associated withsaid member of said set, thereby to provide relationship-based controlfor members of said set.
 2. The dedicated control element of claim 1,wherein said set is defined by a physical relationship within saidenvironment.
 3. The dedicated control element of claim 2, wherein saidphysical relationship comprises a one-way physical relationship with afurther virtual object.
 4. The dedicated control element of claim 2,wherein said physical relationship comprises a two-way physicalrelationship with a further virtual object.
 5. The dedicated controlelement of claim 2, wherein said physical relationship comprises aone-way physical relationship with another member of said set, orwherein said physical relationship comprises a two-way physicalrelationship with another member of said set.
 6. The dedicated controlelement of claim 2, wherein said physical relationship comprises amutual movement relationship, such that said set is defined as the groupof all virtual objects that move when a further virtual object is moved.7. The dedicated control element of claim 1, wherein said set is definedby a logical relationship between virtual objects.
 8. The dedicatedcontrol element of claim 1, configured to recognize a predeterminedtrigger to invoke a corresponding predetermined interaction amongmembers of said set.
 9. The dedicated control element of claim 1,wherein said set controller is configured to process said eventsaccording to a relationship between said three-dimensional virtualobject and said set.
 10. The dedicated control element of claim 1,wherein said set control functionality is configured for processing onemember of the group consisting of events received from any object andapplicable to said three-dimensional virtual object identified asbelonging to said set; and events received from said three-dimensionalvirtual object identified as belonging to said set, thereby to providerelationship-based control for members of said set.
 11. The dedicatedcontrol element of claim 10, wherein said set is defined by a physicalrelationship within said environment.
 12. The dedicated control elementof claim 11, wherein said physical relationship is selected from thegroup consisting of: a one-way physical relationship with a furthervirtual object, two-way physical relationship with a further virtualobject: a one-way physical relationship with another member of said set;a two-way physical relationship with another member of said set.
 13. Thededicated control element of claim 11, wherein said physicalrelationship comprises a mutual movement relationship, such that saidset is defined as the group of all virtual objects that move when afurther virtual object is moved.
 14. The dedicated control element ofclaim 10, wherein said set is defined by a logical relationship betweenvirtual objects.
 15. The dedicated control element of claim 10,configured to recognize a predetermined trigger to invoke acorresponding predetermined interaction among members of said set.
 16. Amethod for controlling functionality of a set of three-dimensionalvirtual objects within a distributed three-dimensional virtualenvironment, the three-dimensional virtual environment implemented onelectronic processors networked together, the method comprising:incorporating allowable functionality for said set of three-dimensionalvirtual objects within a dedicated control element associated with saiddistributed three-dimensional virtual environment, incorporatingidentification functionality within said dedicated control element toenable said dedicated control element to distinguish betweenthree-dimensional virtual objects within said set and three-dimensionalvirtual objects not within said set, and thereby allowing said dedicatedcontrol element to apply rules applicable to said set to control virtualobjects within said set.
 17. A distributed common three-dimensionalvirtual environment implemented on an electronic processor networked toother electronic processors, the common virtual environment comprising:three-dimensional virtual scenery; and a plurality of expert gamecontrol modules, each game control module comprising control andimplementation data for implementing a respectively different gamewithin said three-dimensional virtual scenery.
 18. A server adapted tocommunicate with a remote client, said server implementing a virtualcomputing environment using an electronic processor, said virtualcomputing environment comprising: a plurality of virtual objects, eachvirtual object configured to interact by providing an action in responsewhen presented with a predefined initiating condition by another object,said interacting being a direct reaction to said initiating conditionwithin confines of said environment and giving rise to a directconsequential interaction in a further object, the environment furthercomprising an interaction stopper configured for avoiding undesirablelooping behavior by preventing additional consequential interactionsbetween one of said virtual objects and a later one of said virtualobjects when a number of objects already involved in directconsequential interactions of a given initial interaction reaches apredefined maximum, said preventing comprising configuring saidfollowing object not to provide a consequential interaction in responseto a respective preceding consequential interaction, thereby arrestingundesirable continuation of said looping behavior.
 19. A server asclaimed in claim 18, said relationship with at least said second virtualobject being defined by an order number, said order number being equalto the number of consequentially interacting objects.
 20. A server asclaimed in claim 18, wherein said predetermined interaction limit isspecific to at least one of an interaction order and an interactiontype, and said interaction stopper is operable to stop interactionswithin said specificity.
 21. A server as claimed in claim 18, whereinsaid consequential interaction with said at least second objectcomprises a change in at least one of location, movement, shape, size,status, internal parameters, color and texture of said second object.22. A dedicated control element for controlling the functionality ofvirtual objects belonging to a set of virtual objects within a virtualreality environment, said dedicated control element being implemented onan electronic processor and associated with said virtual realityenvironment, and comprising: identification functionality fordetermining whether a first virtual object within said virtual realityenvironment is a member of said set, and control functionality forprocessing events received from said first virtual object, said eventsincluding events given rise to initial conditions able to cause directinteractions with further virtual objects of said set within saidenvironment, said further virtual objects being directly caused byrespective preceding direct interactions to interact with furthervirtual objects within confines of said environment, said controlfunctionality further comprising an interaction stopper configured toavoid undesirable loops of said consequential interactions by preventingmore than a predetermined number of direct consequential interactionsfollowing an initial interaction within said environment, saidpreventing comprising configuring a further virtual object not toprovide a response to a consequential interaction of a preceding objectwhen said maximum is reached, which response is configured in said laterobject for said consequential interaction of said preceding objectotherwise.